Software programs typically are debugged using a debugger. This debugger will run the program, called the “debuggee,” under its control. The problem debuggers solve is that developers want to be able to stop the debuggee at times, and examine the state of the debuggee. To do that, debuggers generally allow the developer to set breakpoints in source code, and the debugger will stop at those breakpoints, showing the developer the source code, stack, thread, and data views, and allowing the developer to inspect variables.
In many cases, however, source code, stack, thread and data views are not always an optimal or complete representation of the state of the debuggee when stopped at the breakpoint. At times diagrams, schematics, flow charts, tables, or any other visual representation are better suited to show the state of the debuggee. This is especially true in declarative programming, in which the software application may best be depicted using high-level visualizations, such as those mentioned above. Moreover, in some cases, the source code for a software application may be obscured or otherwise unavailable to a developer, rendering source code-level debuggers ineffective at assisting developers in such cases.